Operating systems employ resource management schemes to limit the interference between applications, implement policies that prioritize and otherwise control resource allocations, and generally manage the overall behavior of a system that is running many independent software applications. Usually, a resource manager is provided for each class of devices. Examples of such device classes include, peripheral devices such as keyboards, printers, facsimile machines, scanners, CD and DVD players, network interfaces, smartcard readers, biometric scanners, and memory storage devices (e.g., flash memory). Each of the different classes of devices typically have their own resource manager. Because particular devices within a given class are generally slightly different from one another, an additional software component known as the device driver is commonly provided with each particular hardware device. The device driver acts as a translation layer between the resource manager and the particular hardware device.
Device drivers are commonly used in computer systems as the lowest level software component to communicate with hardware devices. Typically, these device drivers are associated with the devices they control in a one-to-one relationship. For example, a serial port driver is associated with the data/fax serial modem of the computer, an Integrated Switched Digital Network (ISDN) driver is associated with an ISDN interface device, and a network driver provides the interface to a Wide Area Network (WAN) data interface device. In such an arrangement, each dedicated driver manages the start-up, shutdown, maintenance, and functional operations for the hardware device.
Due to advances in technology, it has become possible to integrate multiple hardware devices into a single multifunction device. For example, a single hardware device may be capable of performing one or all of the functions of a data/fax modem, ISDN, and WAN interface. Another example may be a keyboard that has an integrated smart carder reader and a biometric scanner. Such multifunction devices have several advantages over multiple single function devices, including reduced cost, smaller size, reduced load on the host system and easier installation. However, to remain compatible with legacy applications, these multifunction devices still require dedicated drivers for each function, e.g., keyboard, smart card reader, and biometric scanner, etc. Since each device driver functions independently, situations can arise in which multiple device drivers send commands to the single hardware device. Thus, there exists the possibility that the commands sent by one driver may conflict with the commands sent by another driver, resulting in a system malfunction. For example, one driver may send a command to shutdown the hardware device while other independent drivers are using the device. Another example is where one driver attempts to run a diagnostic test that requires exclusive access to the multifunction device to ensure valid results, and another driver attempts to access the multifunction device during this diagnostic test. There are numerous conflicts that can occur with multiple device drivers accessing a single multifunction hardware device.
FIG. 1 illustrates a computer system 10 having a plurality of device drivers, i.e., device driver A 2, device driver B 4, and device driver C 6 being connected to a multifunction device 8. In operation, an application residing on computer system 10 may request a first function to be carried out by multifunction device 8. When a function is requested, computer system 10 directs the driver corresponding to the requested function to send commands to multifunction device 8 in order for it to perform the requested function. For example, if function A is requested, computer system 10 directs device driver A 2 to send commands to multifunction device is 8 to perform function A. However, as described above, some device drivers may issue conflicting commands to the multifunction device. Conflicting commands being sent from different drivers may result from numerous scenarios in a system with a multifunction device. For example, while multifunction device 8 is being directed to perform function A by device driver A 2, computer system 10 may direct device driver B 4 to issue commands to multifunction device 8 to perform function B. Part of the commands issued by device driver B 4 may be device initialization commands which conflict with the commands being issued by device driver A 2. In such cases, the multifunction device may not perform some or all of the requested functions because of the conflict.
In addition to conflicts, another problem that arises when multiple drivers are used with a multifunction device concerns security. For example, it is often necessary to ensure that at any given time, an application is using only one specific function of the multifunction device 8 and that all others are locked down.
One possible solution to this problem is to combine the device drivers into a single multifunction driver, and thereby prevent conflicting commands using programmatic methods. However, this approach may require that a large portion or all of the software code of the existing drivers be rewritten to be able to work as a single driver. This solution also reduces the modularity of the software. A single combined driver is larger and more complex, and therefore is more difficult to create, test, maintain, and upgrade. Combining multiple drivers into a single multifunction driver can increase the total number of drivers required, when all the different permutations and combinations of drivers and multifunction devices are considered. Thus, it is highly desirable to keep the drivers separate.